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1  Objectives  and  Goals 


We  begin  with  a  quote  from  the  section  of  the  same  name  in  the  Statement  of  Work  for  the 
Option: 


The  objective  of  this  effort  is  to  develop  a  system  for  debugging  highly  optimized 
code.  We  propose  to  develop  techniques  whereby  a  user  can  debug  an  optimized 
program  and  yet  be  oblivious  to  the  optimizations  and  at  the  same  time  the 
debugging  technology  places  no  constraints  on  allowable  optimizations.  The  work 
will  develop  a  principled  approach  to  the  construction  of  such  a  system.  It  will  further 
demonstrate  the  validity  of  these  principles  and  the  practicality  of  such  a  system  by 
an  implementation  in  the  context  of  a  state-of-the-art  compiler/debugger  pair. 

We  have  succeeded  in  meeting  these  objectives.  This  report  will  provide  an  overview  of  what  we 
have  done  and  how  we  have  done  it.  The  reader  should  keep  in  mind  that  the  effort  in  this  project 
went  into  constructing  an  innovative,  practical  system,  not  into  this  report.  Even  the  user 
documentation  is  minimal  because  one  of  the  objectives  stated  above  is  that  the  user  be  oblivious  to 
the  capabilities  we  have  provided. 

2  Approach 


We  proposed  to  base  our  effort  on  the  Gnu  compiler/debugger  pair  of  GCC  and  GDB.  GCC  is  a 
state-of-the-art  compiler  that  incorporates  all  the  classical  optimizations,  and  GDB  is  a  better-than- 
most  Unix  debugger.  GCC,  even  before  our  modifications,  was  capable  of  compiling  for  debugging 
(the  -g  switch)  independent  of  the  optimization  level.  (Many  compilers  will  compile  for  debugging 
only  when  not  optimizing.)  However,  the  behavior  of  the  debugger  on  programs  compiled  with 
optimization  can  be  confusing  and  misleading,  and  will  sometimes  not  provide  certain  capabilities  to 
the  user.  Our  goal  here  was  to  remedy  this  confusing,  misleading,  and  missing  behavior.  The  fact 
that  our  goal  was  to  get  GDB  to  behave  “normally”  is  the  reason  for  minimal  user  documentation  of 
our  improvements — GDB  already  has  user  documentation;  our  work  simply  makes  GDB  adhere 
closer  to  that  documentation. 

Our  plan  was  to  consider  two  or  three  kinds  of  optimizations.  Our  resources  were  sufficient 
for  two,  and  we  worked  on  the  two  optimizations  in  the  order  of  priority  that  we  originally  suggested: 
inlining  and  register  allocation.  The  inline  optimization  is  important  because  it  both  is  one  of  the  most 
important  in  speeding  up  programs  (particularly  those  written  in  C++)  and  most  hinders  ones  ability 
to  debug  (ordinarily,  it  is  not  possible  to  set  a  breakpoint  in  an  inlined  function).  After  inlining, 
register  allocation  is  the  most  troublesome  with  respect  to  debugging  because  it  can  hide  the  true 
values  of  variables. 

We  proposed  that  part  of  our  effort  would  be  spend  in  restructuring  GDB  into  a  “top”  part 
providing  the  interface  and  a  “bottom”  part  providing  the  abstraction  of  a  machine  execution.  Once 
we  came  into  close  contact  with  the  reality  of  GDB,  we  realized  that  this  part  of  the  proposal  was 
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naive.  In  some  ways,  GDB  is  in  need  of  such  a  restructuring.  On  the  other  hand,  the  effort  would 
be  massive.  This  is  not  so  much  a  criticism  of  GDB  as  it  is  paying  respect  to  the  fact  that  GDB  can 
debug  programs  on  more  target  architectures,  running  on  more  hosts,  using  more  symbol  table 
formats,  providing  more  features,  than  any  other  debugger.  A  debugger  necessarily  lives  close  to  the 
operating  system  and  close  the  hardware,  and  only  by  examining  the  code  of  GDB  can  one  folly 
appreciate  the  degree  to  which  this  entails  living  dangerously— it  is  foil  of  work-arounds  because  of 
operating  system  bugs,  compiler  bugs,  hardware  quirks,  and  the  like. 

So  instead  of  restructuring  GDB,  we  took  the  opposite  tack  and  left  the  structure  of  GDB  as 
invariant  as  possible,  inserting  all  our  changes  under  conditional  compilation  switches  (bracketed  by 
#ifdef/#endif  constructs).  We  believe  this  will  turn  out  to  be  a  more  pragmatic  approach, 
because  the  changes  can  then  be  distributed  as  part  of  standard  GDB  and  their  use  at  a  particular  site 
is  then  an  installation  option.  We  provided  two  compilation  switches,  one  for  inlining  (LNXI)  and 
another  for  register  allocation  (LNXR).  Each  of  these  switches  applies  both  to  GCC,  where  it 
controls  the  output  of  what  we  call  “linkage  information”,  and  to  GDB,  which  uses  this  linkage 
information  to  hide  the  optimization  from  the  user. 

We  have  used  the  modified  GCC  to  compile  both  itself  and  GDB,  under  various  optimization 
levels  and  for  three  targets.  Further,  the  modified  GDB  passes  the  standard  test  suite.  In  fact,  it 
succeeds  in  a  place  that  the  test  suite  was  expected  to  fail. 

3  Distribution 


We  have  announced  the  availability  of  this  system  to  GCC  and  GDB  interest  groups.  We  are 
releasing  it  as  standard  “patch”  files  based  on  the  most  recent  released  versions  of  GCC  (2.7.2)  and 
GDB  (4. 16).  It  is  available  under  the  standard  GNU  license. 

The  subsections  below  are  the  notes  that  we  distribute  with  the  modifications  to  GCC  and 

GDB. 

3.1  General  Information 


A  modified  GCC  and  GDB  hide  the  effects  of  inline  optimization  and  of  register  allocation.  The  basic 
idea  is  that  with  these  modifications,  GDB  behaves  essentially  the  same  whether  or  not  GCC  has 
compiled  a  program  with  these  optimizations  turned  on.  Details  follow  on  that  “essentially  the  same” 
means.  Keep  in  mind  that  there  is  no  change  in  the  way  that  you  use  GDB;  it  just  behaves  better. 

If  you  already  know  how  these  optimizations  interfere  with  debugging,  skip  this  paragraph. 
The  major  problem  with  inlining  is  that  setting  breakpoints  in  an  inlined  function  has  no  effect  when 
executing  inlined  instances  of  the  function.  A  less  negative,  but  potentially  confusing,  impact  is  that 
you  see  no  stack  frames  corresponding  to  invocations  of  the  inlined  functions — GDB  presents  only 
those  stack  frames  that  correspond  exactly  to  the  physical  stack  in  the  “inferior”,  i.e.,  the  process 
being  debugged.  Further,  the  values  of  arguments  and  results  of  inline  functions  are  available  only 
erratically.  The  major  problem  with  register  allocation  is  that  GDB  will  lie  to  you  about  the  value  of 
a  variable.  This  arises  because  several  distinct  variables  may  be  assigned  to  the  same  register.  Ask 
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for  the  value  of  any  of  the  variables  and  GDB  will  simply  tell  you  the  value  in  that  register,  interpreted 
as  having  the  type  of  the  variable.  A  further  consequence  of  register  allocation  is  that  values  defined 
by  the  program  are  destroyed  by  execution  of  the  program,  and  are  thus  unavailable  to  the  GDB  user. 

GCC  now  works  slightly  differently  with  the  -f  inline  switch,  which  in  the  revised  version 
causes  inlining  whether  or  not  you  have  specified  -O.  Thus,  it  is  now  possible  to  perform  inlining  and 
no  other  optimizations.  Similarly,  GCC  now  has  a  new  -fregisters  switch,  which  causes 
optimized  register  allocation  whether  or  not  you  have  specified  -O.  The  user  may  supply  any  subset 
of  the  -finline  and  the  -fregisters  switches.  The  major  pragmatic  reason  for  the  new 
switch  behavior  is  that  it  enables  working  on  the  optimizations  in  combination  with  each  other  and 
in  isolation  from  other  optimizations. 

A  GDB  user  may  now  set  a  breakpoint  in  a  function  that  has  been  inlined,  and  the  program 
will  break  in  any  of  the  instances  where  the  fiinction  has  been  inlined.  Further,  when  the  user  asks 
to  view  the  stack,  GDB  will  supply  artificial  frames  to  indicate  the  source  semantics  (rather  than  the 
target  semantics)  of  function  calls.  Further,  values- in  these  frames  will  be  available  in  the  usual  way. 
Similarly,  when  a  GDB  user  asks  for  the  value  of  a  variable  which  is  not  “current”,  i.e.,  some  other 
value  is  stored  in  the  variable’s  location,  GDB  will  indicate  the  non-currentness,  either  with  a  “?” 
when  printing  the  parameter  list  in  a  fi'ame  or  by  saying  Value  of  "  .  -  . "  is  unavailable 
here.  In  particular,  you  will  get  this  message  when  asking  for  the  value  of  an  uninitialized  local. 
Further,  GDB  will  often  rescue  the  values  of  variables  destroyed  by  execution,  thereby  making  them 
available  to  the  GDB  user,  who  remains  blithely  unaware  that  without  these  modifications,  GDB 

would  like  about  the  values  of  these  variables. 

At  present,  these  modifications  are  implemented  only  for  the  “stabs”  debugging  format  (used 
by  BSD  systems).  Lamentably,  they  do  not  work  with  the  -gstabs  switch  available  under  some 
systems  (e.g.,  MIPS),  because  these  systems  encapsulate  stabs  in  the  ECOFF  format  in  a  non- 
extensible  way.  It  would  not  take  much  work  to  extend  the  encapsulation  machinery  to  handle  our 
extensions  to  stabs,  nor  to  provide  the  linkage  information  under  other  symbol  table  formats; 
volunteers  are  welcome. 

3.2  When  to  Report  a  Bug 

The  behavior  of  the  modified  GDB  on  programs  compiled  with  or  without  the  -finline  and  the 
-fregisters  switches  is  so  close  that  a  practical  “correctness  criterion”  for  the  modifications  can 
be  stated  in  terms  of  what  differences  can  be  observed.  Users  are  encouraged  to  report  violations  of 
the  following  behavior: 

Compile  a  program  with  the  modified  GCC  in  three  ways;  with  the  -g  switch  only 
(the  “non-optimized”  version),  with  the  -g  switch  and  any  non-empty  subset  of  the 
-finline  and  -fregisters  switches  (the  “optimized  debugging”  version)  and 
with  no  -g  switch,  and  finally  with  the  same  non-empty  subset  of  the  -finline  and 
-fregisters  switches  (the  “optimized  non-debugging”  version). 

The  machine  code  for  the  optimized  debugging  and  optimized  non- 
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debugging  versions  is  identical.  (Great  care  was  taken  not  to  modify  GCC 
to  change  code  generation.  Users  are  encouraged  to  be  very  diligent  in 
reporting  any  failures  in  this  regard.) 

Use  the  modified  GDB  on  the  non-optimized  and  optimized  debugging  versions  of 
the  program,  in  the  ordinary  way.  (There  are  neither  added  nor  deleted  GDB 
commands.)  Then  the  only  detectable  difference  in  the  modified  GDB’s  behavior  on 
the  two  versions  of  the  program  arise  as  follows: 

The  machine  addresses  that  GDB  prints  out  may  differ  (because  inlining 
changes  the  size  of  code). 

The  break  (a.k.a.  b)  command  may  print  out  a  message  Breakpoint 
1  at  Ox/? , .  .  . .  The  ,  . . .  means  that  the  inferior  may  break  at  one 
of  several  pc’s,  all  corresponding  to  the  same  place  in  the  source.  If  the 
function  is  uncompiled  (because  it  is  an  extern  inline  or  because  it 
is  totally  inlined,  either  because  it  is  a  method  in  some  C++  class  or  by  the 
use  of  -03),  //  will  be  0. 

An  uncompiled  function  cannot  be  used  in  expressions.  (It  is  possible  to 
remove  this  restriction,  by  calling  it  from  an  inlined  instance,  but  this  is 
tricky  and  not  worth  it  now.)  Similarly  the  disassemble  and  x 
commands  each  give  an  error  for  uncompiled  functions. 

Some  variables  may  print  as  “?”  or  cause  the  “unavailable”  error,  but  only 
in  situations  in  which  the  variable  has  actually  been  overwritten  with 
another  value,  and  sometimes,  not  even  then  (see  next  item).  (If  the 
variable  is  “dead”  but  happens  not  to  be  overwritten,  you  will  still  be  able 
to  examine  it.)  There  are  still  some  places  where  a  parameter  will 
disappear  entirely  from  GDB’s  knowledge,  but  in  all  currently  known 
cases,  this  is  due  to  some  optimization  other  than  the  two  considered,  so 
is  outside  the  purview  of  the  current  project. 

GDB  will  rescue  the  value  of  an  about-to-be-clobbered  variable  in  any 
function  which: 

-  has  a  breakpoint,  or 

-  has  been  arrived  at  with  a  step,  finish,  or  return  command. 

Call  such  fimctions  “safe”.  Once  a  safe  function  is  entered,  its  variables 
as  well  as  the  variables  of  all  recursive  activations  will  be  rescued,  even 
upon  removal  of  the  breakpoint  which  caused  the  function  to  be  safe. 

The  idea  is  that  the  variables  of  a  function  in  which  a  user  appears 
interested  are  always  available  (once  initialized).  Pragmatics  prohibit 
making  this  guarantee  for  all  the  variables  of  the  program.  The  above 
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rules  seem  a  reasonable  approximation  of  when  a  user  is  interested  in  a 
function,  and  require  no  conscious  effort  or  new  GDB  commands 
Counter-suggestions  are  welcome. 

The  use  of  machine-level  GDB  commands,  eg.,  stepi,  will,  in  general, 
result  in  different  behavior  (because  a  different  machine  language  program 
is  being  run).  Similarly,  “maintenance  commands”  (e  g.,  maint  print 
{,pqTi}  symbols),  which  print  out  internal  GDB  data,  will  of  course  give 
different  results,  and  info  address  and  info  line  behave  slightly 
differently  in  inline  situations.  Likewise,  the  value  of  ^reg  will  vary 
between  the  two  versions. 

The  use  of  -finline  and  -fregisters  in  combination  with  other 
optimizations  does  not  have  similar  guarantee,  but  at  the  very  least,  GDB 
will  not  crash. 

3.3  For  the  Experienced  User 


Supporting  the  above  criterion  required  modifications  to  the  implementation  of  many  GDB 
commands.  These  notes  are  of  interest  only  to  the  experienced  GDB  user,  who  knows  about 
behavior  dependent  on  these  optimizations.  A  naive  user  will  see  only  the  expected. 

frame,  up,  down:  these  introduce  frames  that  are  in  the  source  semantics  but  not 
in  the  inferior’s  physical  stack;  they  are  also  responsible  for  the  “?”  indication  of  a 
parameter’s  unavailability. 

break,  delete,  clear,  info  b:  for  setting,  unsetting,  and  examining 
breakpoints;  the  idea  is  that  one  source  location  may  be  mapped  to  many  pc  values. 

step,  next,  cont,  jump,  until,  return,  finish:  controlling  execution  in 
the  inferior;  some  of  these  are  cute — for  example,  GDB  may  give  the  appearance  of 
entering  or  leaving  a  function  without  ever  running  the  inferior  (because  a  single  pc 
has  an  ambiguous  interpretation  of  being  just  before  or  just  after  a  function  entry  or 
exit). 

list:  for  examining  source  text 

info  line:  if  the  argument  is  an  inline  function,  it  does  not  give  pc  information, 
but  indicates  its  file  and  line;  if  the  argument  specifies  a  line  within  an  inline  function, 
again,  it  does  not  give  pc  information,  but  indicates  that  it  is  an  inline,  possibly 
uncompiled,  function.  (Well,  on  this  one,  maybe  a  naive  user  might  not  expect  what 
happens,  but  it’s  pretty  self-explanatory.) 
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info  address:  indicates  an  uncompiled  function. 


3.4  Pragmatics 


The  additional  functionality  of  GDB  comes  at  some  expense  in  both  compilation  time  and  in  object 
file  size.  The  GCC  file  final .  c,  about  146000  source  bytes,  has  the  following  costs  under  the 
modified  and  unmodified  versions  of  the  compiler: 


modified 

original 

time 

in 

parse 

2 . 840000 

2.970000 

time 

in 

integration 

0.000000 

0.000000 

time 

in 

jump 

0.790000 

0.810000 

time 

in 

cse 

3.660000 

3.630000 

time 

in 

loop 

0.260000 

0.250000 

time 

in 

cse2 

2.800000 

2.710000 

time 

in 

branch-probabilities 

0.000000 

0.000000 

time 

in 

flow 

0.490000 

0.510000 

time 

in 

combine 

2 . 640000 

2.640000 

time 

in 

sched 

0.790000 

0.800000 

time 

in 

local-alloc 

0.690000 

0.710000 

time 

in 

global-alloc 

0.660000 

0.680000 

time 

in 

sched2 

0.450000 

0.510000 

time 

in 

dbranch 

0.890000 

0.880000 

time 

in 

shorten-branch 

0.130000 

0.120000 

time 

in 

stack-reg 

0.000000 

0.000000 

time 

in 

final 

1.160000 

0.760000 

time 

in 

varconst 

0.130000 

0.060000 

time 

in 

dump 

0.000000 

0.000000 

time 

in 

symout 

0.160000 

0.120000 

total 

18.540000 

18.160000 

The  size  of  the  modified  compiler’s  output  is  107301  bytes,  an  increase  of  7.3%  from  the  99933  b)h:es 
produced  by  the  original  compiler. 


We  have  not  done  timing  studies  of  GDB.  Sometimes  it  seems  slower  than  unmodified  GDB, 
particularly,  perhaps,  in  functions  which  have  a  busy  loop  (where  rescuing  is  happening)  and  a  break 
is  set  outside  the  loop.  But  for  the  most  part,  performance  differences  are  imperceptible. 

Although  the  intent  of  this  project  was  to  hide  optimizations  from  the  GDB  user,  a  fallout  is  that 
GDB  informs  the  user  when  variables  values  are  not  available,  regardless  of  the  reason  for  the 
unavailability.  Thus,  the  modified  GDB  issues  an  error  to  a  user  who  is  trying  to  examine  an 
uninitialized  variable  (independent  of  optimization  level).  This  has  prevented  confusion  more  than 
once,  and  is  worth  the  price  of  any  added  GDB  expense. 
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3.5  Caveats 


Although  ever>'  attempt  was  made  to  do  everything  in  a  target-independent  way  in 
both  GCC  and  GDB,  I  have  debugged  GCC  only  on  the  SPARC,  the  MIPS  (the 
exercise  for  the  latter  target  was  the  first  stage  in  discovering  that  -gstabs 
encapsulates  stabs  in  ECOFF  in  a  non-extensible  way),  and  the  j86,  and  GDB  only 
on  the  SPARC  and  386.  All  of  the  development  work  was  on  the  SPARC.  Porting 
GCC  to  the  MIPS  revealed  one  existing  GCC  bug  and  two  from  this  project;  porting 
it  to  the  386  (the  first  non-RISC  platform)  revealed  four  minor  nits.  So  porting  to  a 
fourth  target  will  probably  reveal  some  problems,  but  nothing  major. 

The  system  has  been  used  on  both  C  and  C++  programs,  but  much  more  on  C  than 
C++.  It  has  not  been  used  at  all  on  Modula-2,  Ada,  or  Fortran.  Judging  from  the 
incremental  effort  to  get  C++  working  after  C  was  working  (e.g.,  proper  handling  of 
the  this  parameter  required  a  new  kind  of  information  to  be  transmitted  from  GCC 
to  GDB),  other  languages  will  probably  not  work  out-of-the-box,  but  neither  will  they 
require  much  effort. 

While  combinations  of -f  inline  and  -f  registers  have  been  extensively  tested, 
such  testing  was  not  done  in  combination  with  other  optimizations.  On  the  other 
hand,  this  GDB  was  used  to  debug  GCC  compiled  with  -02,  so  it  is  not  completely 
unrobust. 

The  implementation  assumes  that  a  fimction  begins  and  ends  in  the  same  file.  This 
restriction  could  be  dropped,  but  requires  a  much  more  complicated  internal  data 
structure,  judged  not  worth  it. 

Behavior  is  currently  not  correct  on  inline  functions  with  no  code  at  all.  This  too  can 
be  fixed,  but  in  the  absence  of  user  requests,  seems  less  important  than  other  items  on 
the  agenda.  The  priority  might  change  if  other  optimizations  frequently  optimize 
away  the  contents  of  inline  functions. 

Interaction  with  the  catch  command  has  not  been  tested. 

The  following  comes  from  the  Inline  page  under  GCC  in  M-x  info  (cf  The  above 
discussion  of  the  change  to  the  -f  inline  switch); 

GNU  C  does  not  inline  any  functions  when  not  optimizing.  It  is  not  clear 
whether  it  is  better  to  inline  or  not,  in  this  case,  but  we  found  that  a 
correct  implementation  when  not  optimizing  was  difficult.  So  we  did  the 
easy  thing,  and  turned  it  off. 
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The  scary  part  is  that  in  the  experience  of  this  project,  a  correct  implementaiton  when 
not  optimizing  was  not  only  easy,  but  in  fact  simply  worked  when  tried.  So  who 
knows  what  terrors  lie  in  wait. 

Even  without  trying  it,  the  modifications  are  guaranteed  not  to  work  with  threads. 
The  upgrade  does  not  look  difficult,  but  a  threads  package  was  not  available  for  use 
on  this  project. 

3.6  For  GCC/GDB  Cognoscenti  Only 

This  section  gives  a  brief  account  of  implementation  issues. 

There  are  five  new  kinds  of  “stab”  directives: 

N_INLINE:  marks  an  instance  of  an  inlined  function,  giving  its  name,  where  its 
result  is  returned  (in  the  string,  following  a  in  the  same  way  that  places  of 
locals  are  specified),  and  the  address  at  the  end  of  its  “prologue”  (the  instructions 
that  set  up  its  arguments).  The  immediately  following  block  (balancing 
N  LBRAC/N_RBRAC  directives)  is  the  block  for  the  inline  instance.  Formals 
must  appear  for  each  inline  instance  because,  in  general,  the  formals  are  in 
different  places.  They  places  of  formals  appear  just  before  the  N_INLINE 
directive. 

N  XINLINE:  specifies  an  uncompiled  function.  The  “X”  is  because  the  original 
motivation  was  to  handle  extern  inline,  but  later  it  was  also  found  to  be 
required  for  an  inlined  C++  method  that  does  not  need  to  be  compiled  and  from 
use  of  the  -03  switch.  The  entry  gives  its  name,  result  type,  and  first  and  last 
lines. 

N_OK  and  N_NOK:  these  always  follow  the  stab  for  a  variable,  and  for  a  particular 
variable,  alternate.  They  indicate  where  the  variable  becomes  available  and 
unavailable.  There  are  two  associated  values,  a  delta  and  a  label.  If  the  delta  is 
0,  the  [unjavailability  arises  from  a  control  flow  merge  and  begins  immediately  at 
the  label.  Otherwise,  the  unavailability  is  caused  by  an  instruction  beginning  at  the 
label  and  if  the  variable  becomes  available  there,  is  available  at  or  after  the  label 
+  delta. 

N_JUiylP:  these  follow  the  stab  for  a  fianction  or  for  a  variable.  When  such  a  stab 
follows  a  variable,  it  indicates  a  jump  where  the  variable  needs  to  be  rescued 
(because  flow  leaves  a  place  where  the  corect  value  for  a  variable  is  in  its  location 
to  a  place  where  this  guarantee  does  not  hold.)  The  purpose  of  these  stabs  after 
a  function  stab  is  not  worth  explaining  here. 
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There  is  also  a  new  “Symbol  Descriptor  \  O,  which  says  that  the  variable  is  equal  to  the 
current  value  of  the  frame  pointer  plus  the  value  in  the  stab  entry.  It  is  now  produced  in 
general,  but  has  been  encountered  onlyh  in  connection  with  this  parameters,  which 
necessitated  its  introduction. 

GCC  modifications: 

The  -finline  switch  now  works  as  described  above. 

The  -f registers  switch  was  added,  and  works  as  described  above. 

The  definition  of  tree_block  has  three  new  fields: 

end_prologue;  gives  the  name  of  the  label  at  the  end  of  a  prologue  of  an 
inline  function. 

inline_result:  says  where  an  inline  result  is. 

variables  regions:  encodes  where  each  of  the  variables  of  the  block 
is  and  is  not  available. 

The  inline_flag  of  a  tree_decl,  previous  unused  for  variables,  now 
means  ok_on_entry,  i.e.,  it  is  true  for  parameters  of  a  function  but  not  of  local 
variables. 

CODE_LABEL  rtx’s  have  three  new  fields;  LABEL_U_LIST, 

LABEL_NOK_LIST,  and  LABEL_WAS_OK_LIST.  One  of  these  overlaps  with 
an  existing  field,  so  these  rtx’s  are  now  two  words  longer.  These  rtx’s  also  have 
a  new  flag,  AFTER_BARRIER,  shared  with  the  internal  flag. 

Most  of  the  modifications  to  GCC  have  to  do  with  setting  up  the  above  fields  and 
producing  revised  stab  data  from  them.  It  was  also  necessary  to  be  a  bit  more  careful 
with  the  data  in  the  vars  field,  because  these  supply  the  formals  for  inlined  instances. 

GDB  modifications: 

The  partial_SYnitab  data  structure  now  has  an  inline_names  field  to  tell 
it  whether  it  is  worth  reading  the  full  symtab  to  find  out  more  about  the  uses  of 
an  inline  function  (necessary  when  setting  a  breakpoint  on  an  inline  function). 

The  block  data  structure  now  incorporates  the  following  fields: 
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inline  function:  tells  whether  a  block  corresponds  to  an  instance  of  an 
inline  function,  and  names  the  function. 

end  prologue:  label  after  arguments  have  been  evaluated. 

return_aclass:  address  class  for  the  function  result. 

return_value:  says  where  the  result  is  found. 

The  symbol  data  structure  now  has: 

aux_value .  fun .  {file, line} :  for  a  function,  says  where  it  ends. 

aux  value .  fun .  rescue_juinps:  records  N_JMP  data  for  the  function. 

aux  value .  ok_regions:  for  a  variable,  says  where  it  is  available. 

The  frame_info  data  structure  now  has  an  inline_function  field, 
indicating  the  artificial  frames  mentioned  earlier. 

Additions  to  the  breakpoint  data  structure; 

nuin_inline_breaks  and  inline_breaks:  these  provide  a  list  of  all 
of  the  addresses  in  addition  to  the  (pre-existing)  address  of  the  compiled 
function.  If  the  function  is  uncompiled,  its  address  field  is  -1  (but  prints  as 
0x0). 

sym:  gives  the  function  in  which  the  breakpoint  appears. 

frame  inline  depth:  when  the  frame  field  is  non-null,  this  is  the  depth 
of  the  conceptual  inline  frame  relative  to  the  physical  frame  in  the  inferior. 

watchpoint  frame  inline_depth:  similar  to  the  previous,  but  with 
respect  to  watchpoint_f  rame. 

There  are  two  new  breakpoint  types,  bp_rescue  and  bp_abandon. 

The  enum  address_class  type  has  a  new  member:  LOC_OFFSET, 
corresponding  to  the  O  symbol  descriptor  in  a  stab. 

The  modifications  to  GDB  are  surprisingly  large  in  number,  but  they  all  transact  with 
the  above  additional  fields  of  data  structures  in  more  or  less  obvious  ways. 
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c.  Provides  a  full  range  of  technical  support  to  Air  Force  Material 
Command  product  centers  and  other  Air  Force  organizations; 

d.  Promotes  transfer  of  technology  to  the  private  sector; 

e.  Maintains  leading  edge  technological  expertise  in  the  areas  of 
surveillance,  communications,  command  and  control,  intelligence, 
reliability  science,  electro-magnetic  technology,  photonics,  signal 
processing,  and  computational  science. 

The  thrust  areas  of  technical  competence  include:  Surveillance, 
Communications,  Command  and  Control,  Intelligence,  Signal  Processing, 
Computer  Science  and  Technology,  Electromagnetic  Technology, 
Photonics  and  Reliability  Sciences. 


